Codecov Report

Attention: Patch coverage is 83.98844% with 277 lines in your changes are missing coverage. Please review.

Project coverage is 84.93%. Comparing base (f102e74) to head (3e04526).
Report is 1 commits behind head on master.

@@            Coverage Diff             @@
##           master    #1568      +/-   ##
==========================================
+ Coverage   84.90%   84.93%   +0.03%     
==========================================
  Files          95       95              
  Lines       37255    37250       -5     
==========================================
+ Hits        31631    31638       +7     
+ Misses       5624     5612      -12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Eventually we will do this, but we first need to rebuild all binaries in Oscar that link against flint to use 3.0.0. So we have to put this on hold here for the moment.

We could merge this in a branch and let flint test against that branch. What do you think?

We could merge this in a branch and let flint test against that branch. What do you think?

What's the time frame of the new binaries for Oscar? In the mean time we can just test against my branch in my repo.

There is no real urgency on our side, since there is nothing new in 3.0. So maybe weeks, months?

Just to note it here: Before any merging is done, flintlib/flint#1719 would have to be solved.

is it complicated to fix?

is it complicated to fix?

No, not really. We align by pages, so we either have to use the user-assigned malloc to allocate some more memory than needed (don't know how much we typically allocate), or we have to scrap aligning by pages if user has set the memory functions.

So FLINT 3.0 should not be used with Nemo due to the GC problem, but the upcoming 3.1 should work!

It seems FLINT 3.1 is now out and in a JLL, and as far as I know, this is now supposed to be useable within OSCAR.

Unfortunately this PR now has many conflicts. @albinahlback would you be willing to update it?

It seems FLINT 3.1 is now out and in a JLL, and as far as I know, this is now supposed to be useable within OSCAR.

Unfortunately this PR now has many conflicts. @albinahlback would you be willing to update it?

Sorry, I completely missed this. Will do.

Hopefully this works.

Edit: There were some new(?) functions that did not push any reference to the contexts, should hopefully be fixed now.

@thofma can you check that the fix I made is correct according to the GC?

Btw, how do I run a specific test in Nemo?

Seems to work fine. Let me know if it is and I will squash the commits.

Looks good, thanks

Btw, how do I run a specific test in Nemo?

Once upon a time, one could do something like

Nemo.test_module("flint", "fmpz")

but this is broken.

I took the liberty of splitting this into two commits: one with the "actual" changes, and a second one which takes care of replacing libantic, libarb, libcalcium by libflint. The second commit was made by modifying src/Nemo.jl manually and then doing

git grep -l ccall src test | xargs perl -pi -e 's;lib(antic|arb|calcium);libflint;'

This way it is much easier to see what the "real" changes are.

I am trying this with Hecke. It is not looking good. @albinahlback any hint what Impossible conversion could mean in

     From worker 3:	Flint exception (General error):
      From worker 3:	    Impossible conversion
      From worker 3:
      From worker 3:	[16981] signal (11.2): Segmentation fault: 11
      From worker 3:	in expression starting at
[...]
      From worker 3:	_fq_nmod_vec_clear at /Users/bla/artifacts/fd3613cc70f27c578eab3cfd080ce8edcb3aba44/lib/libflint.19.0.dylib (unknown line)
      From worker 3:	_fq_nmod_poly_clear_fn at /Users/bla/dev/Nemo/src/flint/FlintTypes.jl:6117

I think I found out what the problem is, but it would still be good to know what the "Impossible conversion" hints at.

I will try my best to fix this. But why doesn't this show up in the tests for Nemo?

I don't think there is anything that needs to be changed in order to work? I will just make fq_default_ctx_struct a little bit smaller in Nemo as it is now equivalent to gr_ctx_struct.

The tests are not that extensive. I reduced it to the following change in behavior:

Before:

julia> R = Native.GF(7)
Finite field of characteristic 7

julia> Rx, x = R["x"]
(Univariate polynomial ring in x over GF(7), x)

julia> FqField(x^2 + 1, :asds) |> Nemo._fq_default_ctx_type
2 # corresponds to fq_nmod

With the PR here:

julia> R = Native.GF(7)
Finite field of characteristic 7

julia> Rx, x = R["x"]
(Univariate polynomial ring in x over GF(7), x)

julia> FqField(x^2 + 1, :asds) |> Nemo._fq_default_ctx_type
3 # corresponds to fq

Note that x is an fpPolyRingElem, which is an alias for nmod_poly. If I feed in an nmod_poly, it should construct an fq_nmod disguised as fq_default.

@fredrik-johansson do you know why this is?

P.S.: This is just calling fq_default_ctx_init_modulus_nmod with a plain nmod_poly of degree 2.

Next error/question: What is the recommended substitute for nmod_poly_powmod_mpz_binexp? The history.rst file just told me that is was removed, but not what I should use instead.

Next error/question: What is the recommended substitute for nmod_poly_powmod_mpz_binexp? The history.rst file just told me that is was removed, but not what I should use instead.

nmod_poly_powmod_fmpz_binexp should work. I have tried to remove functions with mpz inputs as that just create duplicate code, and we really want to work with just fmpz.

Thanks

Thanks!

BTW, we will have to push a new patch for this you found, i.e. v3.1.3. (Just one more patch until vπ)

Hm, what happend to fmpz_mod_poly_inv_series_newton?

Fredrik rewrote some code to utilize GR instead. I think it should be replaced with fmpz_mod_poly_inv_series, which then chooses what algorithm to use in the GR module.

I see, thanks

Who should I contact for FLINT_jll? Will soon create 3.1.3.

I created v3.1.3. Please check it out if you have time.

Yes, thanks, I can confirm that the fq_default problems have been fixed. I triggered building the new binaries here: JuliaPackaging/Yggdrasil#8536

But even with this fix, we are still experiencing segfaults in the Hecke tests, which we are investigating. Not sure yet whose fault it is.

What versions of each package should I use to check? Nemo and Hecke have different versions required for AA

I can't get the testing of Hecke to work at all on my system.

There is no need for you to look into it. I will let you know if I find something related.